Shareware Overload Trio 2/Shareware Overload Trio Volume 2 (Chestnut CD-ROM).ISO/dir24/aprs503a.zip/README.RPT

Text File | 1994-01-08 | 12KB | 189 lines

              AUTOMATIC PACKET REPORTING SYSTEM DIGIPEATERS

     To satisfy the objective of instantaneous response, APRS stations are
designed to begin operating without any prior knowledge of the network.  For
this reason, all APRS stations are initialized with the digi alias of RELAY
and to send all UI frames via the path of RELAY.  With this form of generic
alias callsign (RELAY) and wildcard digipeating (RELAY), a mobile, or new
station on the air does not have to know anything about the network in advance,
but to simply turn on his computer to be seen by adjacent nodes.  After 10
minutes and his map begins to show the location of all stations and digipeaters
on frequency, he can customize his outgoing Unproto path to specific
digipeaters to cover his intended area without as much QRM.  It is important
in any APRS network to avoid using the wildcard addressing except when required
to minimize unnecessary QRM on frequency.  Finally in APRS version 3.07, I have
added the DIGIPEATER LIST command so that you can easily see what digipeater
paths that other stations are using.  The minimizing of wildcard addressing
and multiple repeats when not needed is the key to an effecient APRS network.

     Although digipeaters work poorly for AX.25 level 2 connections, they are
ideal for APRS operation using UI frames only.  In the Washington DC area and
Chesapeake Bay area, we are establishing a network of WIDE area DIGI's on the
simplex packet frequency of 145.79.  This frequency is for Keyboard QSO's and
all UI frame applications.  Even leaving Personal mail boxes on the frequency
is welcome, since mail is posted at keyboard rates and is read off-the-air by
the mailbox owner without QRM.  The normal CONNECTED operation of BBS's,
mail forwarding, file transfers, TCP-IP and DX clusters are discouraged!

WILDCARD DIGIPEATING:  To make these WIDE area digipeaters respond to mobiles
and new stations, all wide area digipeaters have the same alias of WIDE in
addition to their normal FCC callsign.  This second generic alias of WIDE
adds tremendous flexibility to APRS networks by significantly extending the
ranges for wildcard digipeating using well situated permanent digipeaters.
These wide area Digi's are spaced several tens of miles apart so that they
are not too close, but that they can hit their adjacent other WIDE digi's.
Assuming WIDE area digipeaters are about 30 to 50 miles apart it is very easy
to select an UNPROTO path prior to a road trip which will assure that your
location packets will always get back to your home area.  The following example
shows a string of digipeaters along the east coast.  The HAM calls of SOUTH and
NORTH are used for clarity.

CALL:   NORTH-3    NORTH-2    NORTH-1   HOME-0    SOUTH-1   SOUTH-2   SOUTH-3
ALIAS:   WIDE       WIDE       WIDE     RELAY     WIDE      WIDE      WIDE

    If the mobile is going south for the day, and will be operating in the
vicinity of SOUTH-3 digipeater, the operator can preset his UNPROTO path to be
via WIDE,SOUTH-2,WIDE.  Notice that not only will his packets make it back to
home from the area of SOUTH-3, but also from the area of SOUTH-1 since SOUTH-1
will also respond to the first WIDE in the list.  Similarly, stations in the
vicinity of SOUTH-3 are alerted to his movements as he leaves home, since the
WIDE,SOUTH-2,WIDE specification is symetrical.  If he set the UNPROTO path to
SOUTH-3,SOUTH-2,SOUTH-1 in the usual manner, he would not be tracked at his
home until he actually arrived at his destination.  As you can see, having the
flexibility to alternate the generic alias's of RELAY or WIDE with other
known sites gives a good degree of flexibility without having to change the
UNPROTO path while on the road.  Using the three digipeater string, he can
wander up to 150 miles in his planned direction and still be tracked by the
XYL.  If he has no idea where he is going, he can always use the path of
WIDE,WIDE or even WIDE,WIDE,WIDE and go anywhere, but with greater QRM on the
channel.  Yes there are multiple collisions, and repeats, but the packet does
get out to the third tier!

PREEMPTIVE DIGIPEATING:   The ultimate APRS digipeater configuration is to have
modified TNC-2 digipeater code so that any digipeater hearing a UI frame with
its callsign anywhere in the UNPROTO path will pause for a reasonable time and
then digipeat the packet as long as it was not previously digipeated by any
stations earlier in the list.  This way, to always report your movements back
home, you always place digipeaters in your UNPROTO command in the reverse
order of your travels.  Your packets will be digipeated back to your home area
as you enter each new digipeater in your direction of travel.  For example, if
you live in the vicinity of DIGI-1 below and routinely travel in the direction
out to and including DIGI-3.


     DIGI-1    DIGI-2    DIGI-3    etc

     If we can get TAPR to modify the code, the mobile could specify the
UNPROTO path of VIA DIGI-3,DIGI-2,DIGI-1 in order to be tracked anywhere all
the way out to the area of DIGI-3.  If only DIGI-1 hears the packet, it will
pre-emptively digipeat the packet and set its digipeat flag.  If DIGI-2 also
hears the original packet, DIGI-2 will pause for P seconds to see if DIGI-1
repeats it.  If so, it does nothing, since DIGI-1 follows it in the list.  If
not, after P seconds, it digipeats the packet for DIGI-1 to subsequently
further digipeat in the normal manner.  Similarly, DIGI-3 pauses for 2*P
seconds to see if DIGI-2 digipeated the UI frame.  If so, it does nothing.  If
not, after the 2*P seconds, it digipeats the packet.  Even if the packet pauses
and comparisons are not performed, (to simplify the code) the worst case is that
N duplicates will arrive at the destination for all N digipeaters that
simultaneously heard the original UI frame.  Since these are UI frames, any
pauses in the network for the comparisons suggested, are not significant.  The
extra code to do the pauses and comparisions only protects against duplicates
when two digipeaters hear the same original packet, and might not be worth the
extra code.

     This algorithm works perfectly well in reverse.  If a mobile desires to
announce his progress forward in the direction of his travel he can specify
the digipeaters in the forward direction.  Then using this algorithm, all of
his packets will be repeated in the forward direction, no matter where he is
along his route, but not in the backward direction.

     Until we get new UI forwarding algorithms in standard TNC's, however,
the general aliases of WIDE and RELAY will do nicely.  If fixed, known
digipeaters are available, even with the generic alias of WIDE, it is best
for fixed APRS stations to use the digipeaters unique callsign instead of
alias to avoid any ambiguity.  Also avoiding the wildcard addresses except
when necessary, significantly reduces QRM on the channel.

     As of version 2.12, APRS now has a special command (Shift-F1) that sets
ones own station to the ALIAS of WIDE vice RELAY.  This is so that an APRS
station that is well situated, can serve as a WIDE digipeater.  This special
command is used to override the automatic TNC initialization routine that
always sets APRS TNC's to the generic alias of RELAY.  This command should be
used with caution and with the understanding of all stations on the net.  Too
many WIDE's and too close together causes too much QRM.  The command has to be
used each time APRS is run, since the initialization routine will always reset
your alias to RELAY.  Also, if you use the Shift-F1 command, your symbol will
be set as a digipeater and the word WIDE will be installed in your POSIT
comment field so that your station will show up on all screens in green.  This
color (showing you as WIDE) will be lost, however, if you have a weather
station hooked up to COM2, since it re-writes the POSIT string every few
minutes.



TheNET CONSIDERATIONS:  I now understand that G8BPQ TheNET code for the
DataEngine includes a DIGIon command that if set to 255 will permit
Digipeating of UI frames only.  Hopefully, other TheNET writers will include
a UI frame only digipeat command.  The problem, however, is that since the
digipeat ALIAS is the same as the NODE alias, you cannot operate more than
one NODE with the ALIAS of WIDE or it will totally screw up the NODE
functions.  We are asking NODES to consider permitting another ALIAS for UI
frames only that is not tied to any of the node functions.

     Since NODES are so much smarter than digipeating, the ultimate solution
is to have the NODES do all UI frame routing.  The APRS station simply sends
his UI frame TO APRS VIA HOME;  Any NODE hearing that transmission that has
knowledge of the route to HOME, will send the single packet via the NODE
network (internode, level 4) to the HOME node!  When it arrives at the HOME
node, it is transmitted once as a UI frame.  With this arrangement, a mobile
only has to specify his one intended destination, no matter where he travels!

DIGI/NODE COMPATIBILITY:  Since the user should not have to change his digi
path as he drives from one area to another, he should be able to specify a
path that is compatible with both nodes and digipeaters.  This is easily
accomplished by assuming that the LAST field in an UNPROTO digi list is the
HOME NODE and should be the ultimate destination for the UI frame through any
level 4 network.  Any and all preceeding fields are assumed to be DIGI's only.
With this arrangement, the user could use an UNPROTO path of APRS VIA WIDE,
HOME so that any generic WIDE digipeaters would repeat his position to their
local area as would any WIDE NODES in the usual digi fashion.  Only the
node that hears the direct packet would also forward it through the network
at level 4 to the HOME NODE.  If only one field is included in the digipeater
string, it would be interpreted as both a digi and a HOME destination without
any difficulty.  Digi's and NODEs would digipeat it, and nodes (hearing it
direct) would forward it at level-4.  It is important that NODES hearing
digipeated UI frames from other digis do NOT enter the packet into the network,
to eliminate duplication.  Only the ones hearing the direct signal should
be repsonsible for doing the level 4 routing..

EXAMPLE:  A typical mobile just wanting to keep his spouse informed of his
whereabouts might want to just use the UNPROTO path of APRS VIA HOME.  Then
his UI frames will be digipeated by the local HOME node or digi and will
also be routed back to HOME by all NET-NODES along his travels.  If he also
wants to be seen by most HAMS in the areas of his travels, then he sets
his path to APRS VIA WIDE,HOME.  If he travels through a region that has
both DIGIs and NODES, he might choose APRS VIA WIDE,WIDE,HOME.  This way any
areas with digis would digipeat via WIDE,WIDE and if he gets to an area with
nodes which are aware of the path to HOME, then they will forward his packet
there.

     Finally, since I hope to build a regional area Tracking network, the node
should also permit the SYSOP to turn off other level 4 routing if he wants to
make a dedicated network of APRS nodes just for tracking.  Such a network would
be swamped if all of the BBS and other CONNECTED protocol users began to use
it, and the original purpose of the network would be defeated.

   Still, most of these APRS support ideas could be included in all NODES so
that a minimum of APRS tracking could be supported by ALL networks on all
frequencies, especially where there is not yet a dedicated APRS TRACKING
NETWORK.  I think there are other undeveloped applications for shipping UI
frames through ALL networks which have not yet been explored.  The capability
should be there, in any case, so that experimentation can proceed.  Time will
tell.  These few paragraphs were primarily written to the NODE CODE writers
such as John G8BPQ and Mr. Roberts of X1-J.  But are included here in general
distribution for all to read.


SEE README.HF for setting up your UNPROTO path for HF and HF/VHF gateways..